1. Field
Embodiments of the present invention generally relate to the field of operating systems. More particularly, embodiments of the present invention relate to enhancement of a general-purpose operating system to function as a symbiotic partner with one or more Customized Execution Environments (CE2s).
2. Description and Shortcomings of the Related Art
The approach adopted by modern general-purpose operating systems has been to define and implement multiple levels of abstractions on top of the actual processor hardware. Such abstractions include multiple virtual memories, multiple tasks (a.k.a. processes or threads), files, sockets, interrupt handlers, semaphores, spin locks, time of day clocks, interval timers, etc.
Some of these abstractions are implemented in the kernels of the respective operating systems, which typically exercise complete control over the actual computational resources of a processor. Such kernels execute at the highest privilege level provided by the processor, enabling the programs comprised by the kernel to execute the “privileged instructions” of the processor instruction set. Operating system kernels manage the creation, scheduling, coordination, and destruction of instances of such abstractions. They also provide for appropriate handling of the entire range of synchronous and asynchronous faults, traps, aborts, and interruptions defined by the hardware processor architecture.
Control of integrated or plug-in input/output device control adapters are implemented by programs called drivers (a.k.a. I/O drivers or LAN drivers or <device> drivers, where <device> is a particular peripheral, bus, or function name). Such drivers also are permitted to execute at the highest privilege level provided by the processor. The amount of code comprised by the drivers usually is larger than the code for operating system kernels themselves.
Other elements implementing the abstractions are built on top of the operating system kernel and I/O drivers. These include file systems, network stacks, synchronization primitives, software signaling mechanisms, sockets interfaces, graphical user interfaces, and various libraries of system services. These elements combine with operating system kernels and I/O drivers to provide an interface to application programs that can be realized on many different hardware platforms.
Indeed, the primary purpose in defining the multiple levels of abstraction provided by general-purpose operating systems has been to develop application interfaces that can be implemented across systems employing incompatible processor and platform architectures. Such portability has been the summum bonum for operating systems. This has been true, in particular, for the UNIX, Linux, and Windows operating systems (ULW operating systems). To date, Linux has enjoyed great success in being ported to many incompatible hardware platforms.
While the program of defining and implementing the multiple layers of abstraction found in today's ULW operating systems has been successful in achieving portability, the result has not been achieved without performance penalties and other negative effects. Two primary such effects will be called the “lowest common denominator” effect and the “semantic mismatch” effect. The first of these effects has resulted in the inability of ULW operating systems to benefit from powerful capabilities present only on some processors. The latter effect manifests either in excessive performance overheads or in system-level functional deficiencies such as scalability and security.
Operating system portability, particularly in ULW systems, has in practice led to two basic categories of consensus. First, there is a broad consensus among the ULW systems as to which abstractions are supported. One cannot find, for example, significant differences among the virtual memory, process-thread-task, file, network, and interruption abstractions of the ULW systems. Second, there is a consensus as to which set of hardware capabilities are supported. This set of capabilities properly can be labeled the architectural “lowest common denominator.”
In the mid 1960s, with the introduction of IBM's System/360, the operating system structure based upon two hardware-enforced levels of privilege was established. The operating system kernel (at the time called the “Nucleus”) and other critical system control code executed at the high hardware privilege level. Other code, including application codes, executed at the low hardware privilege level.
Although several important instruction set architectures have offered four levels of hardware privilege the ULW operating systems never have supported four levels of privilege because such support could not run upon those processors still offering only two levels of hardware privilege. In fact, due to the hardware lowest common denominator effect, the ULW operating systems persist in supporting the 1960's privilege model, with some extensions for read, write, and execute privilege controls. The only truly significant change has been the explosive growth in the amount of code that now executes at the highest level of hardware privilege, a result neither intended nor foreseen by the IBM System/360 architects. Even more powerful addressing control capabilities, such as those offered by PA-RISC® and the Itanium® systems, remain entirely unused by ULW operating systems.
For highly secure systems, in particular, there is compelling need to use finer-grained memory protection capabilities, beyond those that are common to every manufacturer's processors. Support for such capabilities is simply unavailable from any of the principal general-purpose operating systems thereby making more difficult the construction of secure operating systems.
The first category of abstraction consensus provided by the ULW operating systems, like the lowest common denominator consensus regarding hardware features, also results in the collection of functional shortcomings we call the semantic mismatch effect. While the generally accepted operating system abstractions are suitable for a broad class of applications, they are not ideal in every case. No computing structure can be all things to all applications, but force-fitting all applications into solely the generally accepted abstractions is precisely the result of requiring that all applications operate within the ULW operating systems.
Some applications simply cannot work within the limitations of such constraints. Obvious examples are real-time applications, where the system must respond within strict time constraints. General-purpose operating systems usually provide parameters for tuning themselves for the best responses they are able to achieve. However, they cannot always meet the requirements of real-time applications. System designers have addressed such problems in various ways. Some have enveloped a general-purpose operating system within an underlying real-time kernel. In this structure, a real-time structure controls the applications that require guaranteed responsiveness, and the general-purpose operating system controls the rest. Other designers have chosen specialized real-time operating systems, and simply abandoned the attempt to use general-purpose operating systems.
Other applications can be made to function within general-purpose operating systems, but only at the cost of overheads that can substantially reduce system performance. The abstractions provided by the principal general-purpose operating systems are realized only by the expenditure of hardware cycles. The abstractions also have been found not to be low overhead constructs, particularly when considering scalability and security. Defensive validation of arguments is needed at many interfaces, to protect system integrity. Privilege layer crossings can require switching of software (and hardware) stacks. In Helen Custer's book describing the construction of Microsoft's first NT system there is a recurring theme of elegant levels of abstraction leading to unacceptable performance overheads, resulting in redesign and “fast-path” implementations. These occurrences were within the Windows operating system itself. The same syndrome can manifest itself at application levels, where the underlying abstractions offered by the operating system are not a close semantic fit with the needs of the application.
Consequently, if an application's objectives include maximum possible throughput, shortest possible response, and absence of security vulnerabilities the consensus abstractions of general-purpose operating systems can constitute impediments to meeting these objectives.